\chapter{Implementacja}
\label{chap:implementacja}
 W~rozdziale tym opisałam szczegóły implementacji zrealizowanego systemu.
Każda z~części została opisana w~odrębnej sekcji.

  \section{Uwierzytelniane}
 
 
 Platforma GAE pozwala na implementacje uwierzytelniania przy użyciu  adresu poczty internetowej w serwisie Gmail. Udostępniony interfejs zostały wykorzystany w implementacji autoryzacji dla programu budżetu domowego. Po uruchomieniu aplikacji w przeglądarce zostaje sprawdzone, czy użytkownik został uwierzytelniony na swoim koncie Gmail. W przypadku otrzymania odpowiedzi pozytywnej, użytkownik uzyskuje dostęp do swojego konta. Przy każdorazowym żądaniu, wymagającym pobrania prywatnych danych o transakcjach użytkownika, następuje ponowna weryfikacja identyfikatora w celu sprawdzenia, czy nie nastąpiło wylogowanie lub zmiana na inne konto pocztowe. 
 


  \section{Obsługa historii i sterowanie stanem aplikacji}  
      
  Stan aplikacji internetowej odzwierciedla adres URL \footnote{URL --- ujednolicony format adresowania zasobów \ang{Uniform Resource Locator}}. Użytkownik oczekuje, że po wciśnięciu nacisku ,,wstecz'' lub ,,naprzód'' zostanie przeniesiony do odpowiednio poprzedniej lub następnej strony, jaką odwiedzał. Dodatkowo odświeżenie strony nie powinno spowodować przejścia do innego stanu aplikacji. Powyższe wymagania wprowadzają konieczność obsługi historii, co różni tradycyjne aplikacje instalowane na komputerze użytkownika od aplikacji internetowych. W przypadku aplikacji z rodziny AJAX obsługa historii wymaga wprowadzenia dodatkowych mechanizmów, gdyż są one programami wykonywanymi w ramach przeglądarki a nie serią stron HTML.
 
      Podczas implementacji każdej aplikacji internetowej konieczne jest zrozumienie wszelkich zagrożeń związanych z manipulowaniem adresu URL. Użytkownik poprzez modyfikację adresu URL nie powinien  uzyskać dostępu do poufnych danych innego użytkownika. Ponadto nie powinno być możliwe, aby potencjalny włamywacz mógł doprowadzić do wyświetlenia w oknie przeglądarki błędów wynikających z błędów języka implementacji aplikacji, czy też nieprawidłowego zapytania kierowanego do bazy danych. Dane te mogą być bowiem wykorzystane do przeprowadzania włamania.
      
 Implementacji modułu zarządzającego historią i modyfikującego parametry URL w aplikacji budżetu domowego zakłada współpracę z szyną zdarzeń udostępnioną przez technologię GWT. Każde przejście do innej strony wiąże się z wysłaniem zdarzenia zmiany miejsca. Podstawowa mechanizm obsługi historii  dostarczony jest przez technologię GWT, jednak rozwiązanie to wymagało po stronie aplikacji:
           \begin{enumerate}
        \item  stworzenia klas definiujących miejsca (ang. Place), które reprezentują określony stan interfejsu użytkownika. Każdy z obiektów ma przypisany unikalną ścieżkę dostępu;
       \item stworzenie klas odwzorowujących określone miejsca na aktywności (ang. Activities);
       \item stworzenie aktywności (ang. Activities) pełniących funkcje prezentera ze wzorca MVP i wykonujących operacje na widoku.
        \end{enumerate}
        


Zmiana miejsca może nastąpić z poziomu przeglądarki (np. po naciśnięcie przycisku "wstecz", własnoręcznej zmianie adresu URL) lub programowo z poziomu aplikacji.

  \begin{figure}[h]
    \centering
    \includegraphics[width=\textwidth]{obrazy/a&p.pdf}
    \caption{Wymuszenie zmiany miejsca z poziomu przeglądarki}
    \label{fig:ap1}
  \end{figure}

Rysunek \ref{fig:ap1} przedstawia sytuację zmiany miejsca z poziomu przeglądarki. W tym przypadku zarządca historii miejsc czeka na wystąpienie zmiany adresu URL. Gdy ta sytuacja nastąpi, na postawie ścieżki następuje wybór odpowiedniego obiektu miejsca, który następnie przekazywany jest kontrolerowi operującemu na szynie. On jest odpowiedzialny za umieszczenie zdarzenia zmiany adresu URL na szynie. Podstawowym zadaniem zarządcy aktywności nasłuchującego na szynie jest wywołanie odpowiedniej aktywności. Wybór ten następuje przy udziale modułu odwzorowującego miejsce na aktywność. Aktywność następnie wyświetla uaktualniony widok.

  \begin{figure}[h]
    \centering
    \includegraphics[width=\textwidth]{obrazy/a&p2.pdf}
    \caption{Wymuszenie zmiany miejsca z poziomu aplikacji}
    \label{fig:ap2}
  \end{figure}
  
Rysunek \ref{fig:ap2} przedstawia sytuację zmiany miejsca wymuszoną z poziomu aplikacji. W tym przypadku inicjatorem zmiany jest sam widok lub aktywność. Aby przycisk przeglądarki ,,wstecz'' nadal spełniał podstawową funkcję, musi nastąpić poinformowanie historii przeglądarki o zdarzeniu zmiany adresu URL.  

 Przedstawione rozwiązania, choć na pozór mogą wydawać się mało przejrzyste, pozwalają na niezależny i efektywny rozwój aplikacji.  W przypadku konieczności stworzenia dodatkowego ekranu, należy dokonać jedynie rejestracji miejsca u zarządcy historią i w obiekcie klasy odwzorowującej. Nie jest zaś niezbędne poznawanie sposobu działania i struktury innych widoków, ani zmiany w nich. Gdyby w przyszłości, w rozwoju aplikacji miałaby uczestniczyć kolejna osoba, która nie znałaby implementacji programu, musiałaby jedynie zrozumieć podstawowy sposób sterowania aplikacją, aby móc dodawać kolejne ekrany.


 
  \section{Dostęp do danych}
  
  W warstwie dostępu do danych wykorzystano wzorzec DAO \footnote{DAO --- obiekt dostępu do danych \ang{Data Access Object}}, który zakłada separację obiektów zawierających dane zapisywane do tabel od wykonywanych na nich czynności. Wzorzec DAO zakłada istnienie niezależnej klasy DAO dla każdej klasy DTO \footnote{DTO --- obiekt transferujący dane \ang{Data Transfer Object}}. Klasy DAO muszą zawierać podstawowe operacje, takich jak: zapisywanie, aktualizacja, wyszukiwanie i usuwanie. 
       \begin{figure}[h]
    \centering
    \includegraphics[width=\textwidth]{obrazy/diagram_klas1.eps}
    \caption{Diagram klas dostępu do danych}
    \label{fig:dk}
  \end{figure}
   
W celu uniknięcia powtórzeń analogicznej implementacji funkcji we wszystkich klasach DAO, zdecydowano się na wprowadzenie generycznego rozwiązania (rysunek \ref{fig:dk}). Stworzony interfejs GenericDAO określa, jakie podstawowe operacje ma wykonywać klasa DAO. Nie definiuje on wykorzystanych danych - typu identyfikatora obiektu DTO, ani samego obiektu DTO. Klasa implementująca - JdoDAO określa typ identyfikatora DTO, ale nadal nie jest związana z żądnym obiektem transferu danych. Posiada ona kompletną implementację podstawowych metod, która będzie wykorzystywana przez obiekty wszystkich konkretnych klas DAO. W przypadku zmiany standardu mapowania obiektowo-relacyjnego, interfejs GenericDAO byłby nadal aktualny, należałoby jedynie podmienić klasę implementującą.
  

  
    \section{Synchronizacja z kontami bankowymi}
    
Wymagania funkcjonalne aplikacji budżetu domowego zakładają możliwość importowania danych o operacjach finansowych z kont bankowych. Nie jest możliwe stworzenie uniwersalnej implementacji, która umożliwiłaby import ze wszystkich banków, gdyż każda z tych instytucji posiada własny sposób opisywania transakcji finansowych. Istnieją dwa podstawowe, programowe sposoby pozyskania listy operacji z konta klienta banku. 

Pierwszy z nich zakłada udostępnienie aplikacji nazwy użytkownika i hasła do systemu bankowości internetowej. Aplikacja po uzyskanie dostępu do konta mogłaby pobrać listę operacji na podstawie wiedzy o budowie systemu. Rozwiązanie to pod wieloma względami jest jednak mało bezpieczne. Nawet jeżeli hasła nie będą zapisywane i będą przesyłane w bezpiecznym, szyfrowanym połączeniu to nie wyeliminuje to faktu, że tak naprawdę aplikacja ma dostęp do wielu danych, do których mieć nie powinna. Teoretycznie istniałby możliwość pobrania przez aplikację budżetu domowego informacji o danych klienta z systemu bankowego, które pozwoliły na zmianę hasła w tym systemie lub wykonywanie operacji bankowych. 

Drugie rozwiązanie umożliwiające import operacji bankowych zakłada, że system bankowy pozwala na eksportowanie listy operacji bankowych do pliku. Użytkownik jest odpowiedzialny za udostępnienie pliku aplikacji budżetu domowego. Podejście to nie wymaga podawania haseł, lecz nie pozwala na automatyczną synchronizację z kontem bankowym. Na użytkowniku spoczywa odpowiedzialność troski o aktualizację listy operacji. 

W implementacji budżetu domowego wykorzystano drugie z opisanych rozwiązań. Import wyciągów możliwy jest z banku mBank. Dalszy rozwój aplikacji zakłada rozszerzenie listy dostępnych banków. W celu dokonaniu importu transakcji użytkownik musi wygenerować plik CSV(format przechowywania danych w plikach tekstowych) w systemie internetowym banku oraz udostępnić go aplikacji. Niestety, automatyczne rozpoznanie kategorii wydatku lub przychodu okazało się bardzo trudne w implementacji. Spowodowane było to najczęściej brakiem odpowiednich informacji w opisie operacji udostępnionym przez bank. Przykładowo, jeżeli została wykonana operacja zakupu przy użyciu karty w restauracji, w tytule transakcji pojawiało się jedynie ,,Zakup przy użyciu karty lokal 4806 /Warszawa''. W opisie nie występuje nazwa restauracji, jest jedynie numer roboczy. Liczbę można byłoby zinterpretować, posiadając wiedzę, jak każdy punkt gastronomiczny definiuje swoje operacje. Z powodu powyższych utrudnień ostatecznie zrezygnowano z automatycznego przydzielania kategorii. Na użytkownika została przeniesiona odpowiedzialność przypisania kategorii do wydatków i przychodów zaimportowanych z wyciągu.